During the development of 2G mobile systems, complete sets of networks, teleservices, applications and supplementary services were ubiquitously specified by standardization bodies. A common interest of the industry has, however, been to shorten the specification time of service enablers, fasten the introduction of new services and enable seamless scalability of services. At 3G development, the approach has thus been focused to standardizing service capabilities, instead of the services per se.
ETSI (European Telecommunications Standards Institute) defines service control as an ability of a user, home environment or serving environment to determine what a particular service does, for a specific invocation of that service, within the limitations of that service. Basically this means that the architecture of any system should provide a service framework that facilitates appropriate security, quality of service, charging, and session management to support the various services within that system. Initially a number of service enablers, like digital rights management and push to talk over cellular (PoC) service, used to generate service control models more or less independently, merely as a response to the clear customer need. Later, different services enablers have been co-operating under a global organization called the Open Mobile Alliance (OMA) to utilise an infrastructure that provides the required basic capabilities.
For the time being, the infrastructure is called the Internet Protocol Multimedia Subsystem (IMS). It relates to an access-independent IP-based architecture that interworks with existing voice and data networks accessible by both fixed and mobile users. The IMS architecture facilitates peer-to-peer IP communication with various types of clients with the requisite quality of services. The IMS is based on the specification of the Session Initiation Protocol (SIP) as standardised by the Internet Engineering Task Force (IETF). So called Release 5 introduced IMS as part of 3GPP standards. A number of IMS specifications are made publicly available by 3GPP and OMA.
A session relates to an interval during which a logical correspondence between two objects exists for the transfer of related information. A session can include, for example, transmission of voice or video data. In IMS, the selected application-layer control protocol for creating, modifying, and terminating sessions with one or more participants is Session Initiation Protocol (SIP). Users may have several connections to different service applications during a session. For each IMS session, the service control of IMS maintains a session state, interacts with service platforms and charging functions as required by the service. The logical network element responsible for these functions is called the Serving Call Session Control Function (S-CSCF).
In the IMS architecture, services are hosted and executed in service platforms, Application Servers (AS). For sending and receiving SIP messages between the S-CSCF and AS an IMS Service Control reference point (ISC) is defined between the S-CSCF and AS. When the S-CSCF receives a SIP request, it will analyze it and decide to route the request to an AS for further processing. The analysis is based on a service profile associated with a public user identity indicated in the request. The service profile relates to a collection of user-specific information (e.g. filter criteria) that is made available to the S-CSCF at least during the time the S-CSCF performs data handling operations of that particular user. Typically the service profile or at least the filter criteria are downloaded to S-CSCF on user registration or when a terminating initial request is received for an unregistered user.
A service profile of an IMS subscription comprises filter criteria that describe one or more conditions that are checked to decide whether an incoming SIP message should be further routed to an AS for further processing. The filter criteria also specify the particular AS to be contacted whenever the conditions are met. A filter criterion thus represents a provisioned subscription of a user to an application or applications.
The capability of a user agent (UA) to utilize a provisioned application may, however, change dynamically. According to RFC 3840, a capability is defined as an attribute of a sender or receiver that indicates an ability to generate or process a particular type of message content. A capability is distinct from a characteristic in that a capability may or may not be utilized in any particular period, for example during a single call, whereas a characteristic is a non-negotiable property of a UA. For example, user agents may vary widely in their capabilities and in the type of devices they represent. Filter criteria is, however, a substantially static definition that does not facilitate dynamic variations caused by, for example, the capability of the current terminal equipment in use.
For example, an IMS user may have been subscribed to use a PoC service, but has currently not registered as a PoC user, because he or she is presently using a terminal without PoC capability. When an incoming request addressed to that IMS user is received by S-CSCF, S-CSCF analyzes the request and compares it against the filter criteria. The filter criteria state that if the request comprises PoC service capability indication, the message has to be forwarded to a defined PoC AS. IMS service control naturally comprises a mechanism whereby AS may detect the mismatch and appropriately terminate the session initiation. However, at that time the routing has already proceeded all the way to the AS. This adds superfluous load to the PoC server and, depending on the answer mode setting within the PoC server, may generate charging activities that need to be agreed and arranged separately, for example the charging records have to be cancelled/revoked. Furthermore, this is a severe technical drawback that compromises the acceptance and implementation of services in IMS systems.